Integrated circuits (sometimes referred to as “silicon” by design engineers) contain an ever increasing number of devices that provide an ever increasing amount of functionality. As a result, it is becoming an ever more important, and time consuming, task to determine whether an integrated circuit performs as intended, i.e., in conformance with its design. To do this, design engineers have test engineers test the integrated circuit's response to a number of predetermined stimuli to verify that the integrated circuit will provide predetermined results. For example and without limitation, functional tests are performed wherein predetermined patterns of data are presented to predetermined inputs of the integrated circuit in predetermined time sequences, and outputs are measured at predetermined time sequences. The results of these tests are examined to verify and debug the design of the integrated circuit, i.e., to determine whether the integrated circuit operates satisfactorily.
Referring to FIG. 1, a debugging scheme in accordance with the prior art is shown that facilitates determining whether the integrated circuit operates satisfactorily, i.e., in accordance with design criteria. To that end, a software application running on a suitable computer system uses design data base 10 corresponding to the integrated circuit to generate an output file (referred to herein as a “design pattern”) by running a simulation at step 20. At step 30 of FIG. 1, the design pattern is provided as input to a translator and test program generator to translate the design pattern to a tester pattern, and to generate a test program used by a tester. At step 40 the tester applies the tester pattern to the integrated circuit, referred to as a device under test “DUT”. To that end, the integrated circuit is mounted to the tester, and the test program, generated at step 30, is loaded into the tester. Next, as indicated by decision box 50, the results of each test performed on the DUT by the tester are evaluated. If any test is failed, as indicated at step 60 of FIG. 1, the results of the failure are stored in an output file referred to as a datalog. Otherwise, debugging ends at step 70.
FIG. 2 shows an exemplary design pattern 80 generated at step 20 of FIG. 1 and includes input data 82, output data 84, and clock signal 86. Input data 82 is stimuli applied to the integrated circuit by the tester. Output data 84 are simulated responses, which are to be expected if the integrated circuit were to operate in conformance with design parameters. For example, a typical such design pattern (or stimulus-response file) comprises logic values to apply to various pins of the integrated circuit (for example, high or low values) at various times. Further, a typical such design pattern (or stimulus-response file) also comprises logic values expected to be observed at various pins of the integrated circuit (for example, high or low values) at various times if the integrated circuit were to operate in conformance with its design. In the prior art, a typical such design pattern (or stimulus-response file) is formatted in a file that is sometimes referred to as a value change dump (“VCD”) file. As is known, in one embodiment in the prior art, a VCD file is an ASCII file that contains header information (for example, a data, a simulation software version number used to produce the file, and a timescale used), variable definitions (for example, definitions of the scope and type of variables in the file), and value changes for the variables (i.e., information about value changes on selected signals and time entries every time there is a state change on a pin). Typically, the simulation times recorded in the VCD file is an absolute value of the simulation time for changes in variable values that follow. Clock signal 86 includes a predetermined number of cycles to account for “real time” events taken into account to test the integrated circuit.
FIG. 3 shows an exemplary test pattern 90 generated at step 30 of FIG. 1 and includes input data 92, output data 94, and clock signal 96. Clock signal 96 includes a predetermined number of cycles to account for “real time” events taken into account to test the integrated circuit. Examples of “real time” events include the time required, for example, for a phase-locked loop to stabilize and/or the time required for a predetermined reset sequence to be carried out. In practice, the translator may be part of a test program generator that generates the test program that will be executed by the tester. The test program typically includes a data base of external signals and their type (thereby determining what tests need to be performed), and appropriate executable program code for the tester. For example, step 30 is performed to translate “event-driven” vectors of the VCD file to “cycle-based” vectors used by testers (this step is sometimes referred to as “cyclization”). For example, in a cycle-based vector format, there is only a single vector entry for each clock cycle (assuming a synchronous system), whereas event-driven vectors typically have numerous vector entries for each cycle indicating time-positioning of all of the transition edges for signals in the file throughout a simulation run. The translation process is performed under user control (many computer programs exist for translating VCD files into a format that is useable by a tester). Typically, the translator is configured, for example, by a test engineer, with what is sometimes referred to as a recipe file. The recipe file may specify: (a) which pins in the VCD file are input pins and which are output pins; (b) how to map state characters between the two format; (c) how to deal with bi-directional data; (d) perhaps some desired signal masking; (e) particular frequencies at which to perform particular tests; (f) desired tester program output format; and (g) so forth.
FIG. 4 shows an exemplary portion of a datalog 100 generated at step 60 of FIG. 1. Datalog 100 includes information concerning the “FailLocation n” which indicates the identity of the “failure location.” This may be specified, for example, by associating a clock cycle number during which a failure occurred. Further, for each failure location, there is a list of: (a) failed pins, (b) fail seq. logic values (i.e., the measured logic values for the pins associated with the failure indication), and (c) expected seq. logic values (i.e., the expected logic values for the pins associated with the failure indication had the circuit operated in conformance with its design).
Although datalog 100 contains a record of the DUT's performance on each test, it is difficult for a design engineer to analyze the datalog. The difficulty arises because datalog 100 is typically provided in a format that relates to that of the tester rather than a format that relates to that of the design pattern that the design engineer is used to reviewing. In particular, due to cyclization, it is not readily apparent to the design engineer how a clock cycle in datalog 100 relates to a particular time in the design pattern. Further, due to cyclization, logical signals in the tester pattern, and hence datalog 100, very often have no relationship to logical signals in the tester pattern. Further, datalog 100 often includes symbols for logical signals that are not familiar to the design engineer.
All of the above presents a problem because design engineers are not readily able to compare the design pattern with datalog 100. As a result, design engineers who debug circuit designs must spend many hours with test engineers just to understand the nature of the problem. In fact, and in practice, even after spending many hours with test engineers, design engineers have difficulty correlating datalog 100, shown in FIG. 4, with design pattern 80, shown in FIG. 2, and therefore debugging the design of the integrated circuit. This problem is exacerbated by the fact that many different tester formats are used. Thus, even when the data contained in datalog 100 is printed on paper, and an operator compares the printout with a corresponding printout of responses generated in accordance with design requirements to determine whether the integrated circuit operated in conformance with its design, this is a slow, cumbersome process that is prone to human error.
In light of the above, there is a need in the art for method and apparatus for solving the above-identified problem.